Skip to content

Add headings and other geometric pins in motion using State_tags#3995

Open
rodw-au wants to merge 61 commits into
LinuxCNC:masterfrom
rodw-au:state-tags-arcs
Open

Add headings and other geometric pins in motion using State_tags#3995
rodw-au wants to merge 61 commits into
LinuxCNC:masterfrom
rodw-au:state-tags-arcs

Conversation

@rodw-au
Copy link
Copy Markdown
Contributor

@rodw-au rodw-au commented May 2, 2026

Outline

create new [motion.interp.xx ] pins for heading and various geometric data (refer man motion for this PR). Note the following use cases behind this PR.

  • heading requested by Andy as it was trivial to add while working on this. Its been in Mach3 for years. Useful for tangential knives and saws.
  • normal-heading angle from current position to arc centre. Allow bevelled cutting in conjunction with heading. This could allow cuttings of bevels (eg with a plasma torch) with 2D gcode. While torch holders exist that keep the angled torch tip axial to the Z axis, external offsets could be used to calculate the desired XYZ coordinates to centre the torch tip
  • radius A theory of mine. Plasma cutters use torch voltage as a process contol variable to set torch height to obtain even kerf but this assumes a constant velocity (reducing velocity increases torch voltage). When the torch aproaches a centrepetal radius limit, the system could lock the height and switch to using current as the process control variable to keep the voltage constant.
  • iscircle allows a plasma cutter to detect bolt holes (where arc start position = end position) and apply custom hole processing rules more inteligently than the current state. Can be used in conjunction with normal-heading for countersinking holes.

I am sure the community will find many other use cases.

Code notes

  • Uses an extension of state_tags.
  • New procedures tag_straight() and tag_arc() in interp_convert.cc apply our new tags for straight moves and arcs.
  • Because these tags are only applied at the beginning of a segment, heading calculations are applied in motion/control.c/update_status() in real time.
  • The rest of the code is mechanical to transfer the tags added by the interpreter back to motion so the data can be used in real time.
  • May provide a framework for using additional tags in motion

Caveats

We use the state tag motion_type (GM_FIELD_MOTION_MODE) to detect G0,G1,G2,G3 in motion. Currently there is no way to use existing interpreter equates for these values so the numbers are hard coded as 0,10,20,30.

RunTests

These pass locally

Runtest: 278 tests run, 278 successful, 0 failed + 0 expected, 4 skipped, 0 shmem errors
rod@debian:~/devt/linuxcnc$ 

Acknowledgements

Many thanks to Luca Toniolo (grandixximo) for his encouragement and help resolving errors with the tests.

Rod and others added 14 commits April 13, 2026 17:44
merge latest upstream into state-tags-arcs branch
merge master to state-tag-arcs branch
…d read

active_modes() in rs274ngc_pre.cc still ran the original unclamped loop
above the clamped one, so the stack overflow into saved_settings[5] was
unchanged. The line-number copy was also commented out. Drop the duplicate
and restore the line-number copy.

write_state_tag() still dereferenced block on the iscircle assignment
(`block->iscircle = (block == NULL) ? 0 : block->iscircle`), reintroducing
the M70 NULL-deref. Replace with a plain null-guarded read.

control.c output_to_hal() read the iscircle bit out of `tag.fields[]` using
the StateFlag index GM_FLAG_IS_CIRCLE, which indexes past `fields[]`
(GM_FIELD_MAX_FIELDS == 8). Read it from packed_flags instead, like the
update_status() copy does. Also dropped the duplicate
interp_normal_heading write in the G2/G3 branch and restored the
WATCH_FLAGS debug block to live inside update_status().
Round 2: re-fix M70 segfault and iscircle handling
M_PI_2 is a glibc extension and is not exposed by RTAI's rtapi_math.h,
so the RTAI build fails with 'M_PI_2 undeclared' at control.c:2283.
M_PI is available in both, so use M_PI/2.0 instead.
@BsAtHome
Copy link
Copy Markdown
Contributor

BsAtHome commented May 3, 2026

Some observations:

  • Why is there a file called arc_heading?
  • I'm not sure that creating test-files in the root LCNC directory called nc_files is a good idea. Tests are supposed to be in the tests directory and have a real test associated. If they are not for testing, then you need to have a specific config and the should be created in the config/sim/... somewhere as an example.
  • The line docs/man/man9/output_buffer.9 is malplaced in the root .gitignore and should be in the docs/man/.gitignore file. However, it is probably malplaced in this PR as it seems unrelated to this PR.
  • The diff of src/emc/rs274ngc/interp_convert.cc is 7000+ lines. Most, if not all, seems to be inappropriate (or stylistic wrong) white-space changes. What are the actual differences in this file?

@rodw-au
Copy link
Copy Markdown
Contributor Author

rodw-au commented May 3, 2026

Thanks for the feedback.

  1. I will remove the spurious (empty) arc_heading
  2. The nc_folder was created due to issue RIP build now makes a temp file or folder (I think called $) in the working directory where linuxcnc 2.10pre is invoked from the command line #3924 . I reported which was not resolved until after I commenced work on this PR. I will remove it as there is no need to demonstrate these pins with a custom sim. (I just used the normal axis sim for testing)
  3. docs/man/man9/output_buffer.9 I think appeared on acceptance of a PR from Luca so not sure how to remove it. It seems to be created again in the build process and is not part of this feature. Added to docs/man/.gitignore
  4. Sorry if the style has been broken. Changes in interp_convert.cc are two new procedures at the end tag_straight() and tag_arcs() which are each called once from convert_straight() and convert_arc2(). New procedures are from line 7080 and on. Probably easiest to review in my fork; state_tags_arcs branch. https://github.com/rodw-au/linuxcnc/blob/state-tags-arcs/src/emc/rs274ngc/interp_convert.cc#L7080

Ideas to resolve Item 3 would be appreciated.

Just reviewing further, it appears #3924 that the ~/linuxcnc/configs folder contents have been added to the root folder on my PC. I don't think they have been included in this PR. Could someone please check and confirm?

…that was not resolved when work commenced on this PR.

2. Deleted spurious arc_heading file.
3. Moved docs/man/man9/output_buffer.9 to docs/man/.gitignore
@hansu
Copy link
Copy Markdown
Member

hansu commented May 3, 2026

docs/man/man9/output_buffer.9 I think appeared on acceptance of a PR from Luca so not sure how to remove it. It seems to be created again in the build process and is not part of this feature. Added to docs/man/.gitignore

Sorry my fault, I forgot to add the generated man page to gitignore (#3941)

@BsAtHome
Copy link
Copy Markdown
Contributor

BsAtHome commented May 3, 2026

Hm, I'm not sure I've been looking too good at the nc directory... Point 12 makes 300+ files disappear. That seems very, very wrong. (edit should read point 2)

Point 3 should be a separate PR, I guess.

Point 4 needs to be solved by you taking the original file and only change what is necessary.

@BsAtHome
Copy link
Copy Markdown
Contributor

BsAtHome commented May 3, 2026

Just to add a comment on nc files.

It is not that you cannot or should not add (example) files. The point is that there needs to be some kind of docs or procedures that use or reference them. Just having files without people knowing how to find them is kinda pointless.

@BsAtHome
Copy link
Copy Markdown
Contributor

BsAtHome commented May 3, 2026

docs/man/man9/output_buffer.9 I think appeared on acceptance of a PR from Luca so not sure how to remove it. It seems to be created again in the build process and is not part of this feature. Added to docs/man/.gitignore

Sorry my fault, I forgot to add the generated man page to gitignore (#3941)

You are not the first who gets bitten by this. There is a change in the works to let CI fail when this happens.

@rodw-au
Copy link
Copy Markdown
Contributor Author

rodw-au commented May 3, 2026

Just to add a comment on nc files.

It is not that you cannot or should not add (example) files. The point is that there needs to be some kind of docs or procedures that use or reference them. Just having files without people knowing how to find them is kinda pointless.

As mentioned in the original comment, these new pins are documented in the motion man file eg man motion under I_Interpreter Metadata pins._ These should find hteir way to the web site shouldn't they?

Re point 2, you now see the problem with the nc_files folder caused by #3924 . I too only saw it it when the files were removed by git add. It was very wrong as it created the files that should have been under ~/linuxcnc in whatever was the current working directory. So saving the sim to your desktop created this mess!

@BsAtHome
Copy link
Copy Markdown
Contributor

BsAtHome commented May 3, 2026

As mentioned in the original comment, these new pins are documented in the motion man file eg man motion under I_Interpreter Metadata pins._ These should find hteir way to the web site shouldn't they?

The man page is a reference for the component. These man pages usually do not do a lot of examples. For that we have the other documentation in the docs/src directory, where specific scenarios are described and more in depth explanations are (should be) presented. This is usually also the place, while explaining and going into depth, to reference the examples provided.

Re point 2, you now see the problem with the nc_files folder caused by #3924 . I too only saw it it when the files were removed by git add. It was very wrong as it created the files that should have been under ~/linuxcnc in whatever was the current working directory. So saving the sim to your desktop created this mess!

Yes, there was that unfortunate wrong side-effect while fixing the Tcl9 compatibility problem, sorry about that. However, it should be fixed now, isn't it?

@BsAtHome
Copy link
Copy Markdown
Contributor

BsAtHome commented May 3, 2026

These should find hteir way to the web site shouldn't they?

Man pages should find their way, yes. So does the other documentation afaik.
(if auto updating works, don't know about that)

rod added 2 commits May 4, 2026 07:47
in preparation to fix format errors caused by editor auto format options
Aditional commit to follow
then reapplying chnagfes in this PR to it
@rodw-au
Copy link
Copy Markdown
Contributor Author

rodw-au commented May 3, 2026

Formatting issue in interp_convert.cc was caused by an errant autoformatting editor I had no idea about.
I reverted to a copy from master branch than reapplied the changes from this PR so the last commit 5461c2d now shows changes nice and clearly.

I can't see a clean way to correct the .gitignore issue by a PR from the oversight in #3941. Its been corrected in this PR.

Re documentation, when I look at a the docs page on the web site, I can't see any chapter where additional documentation of a few extra pins is appropriate except for the man page. Perhaps these gcode samples could be deployed and mentioned on the man page but where do I put them so they turn up in the users nc_file examples?
nc_files.zip.

Adding example gcode for read only pins just does not seem right to me. The man page should be sufficient (as it is for every other component).

All runtests pass
Runtest: 278 tests run, 278 successful, 0 failed + 0 expected, 4 skipped, 0 shmem errors

I think this is now OK for approval. It is benign as it does not add any additional features, just exposes some useful information. Breakages are unlikely. Any fixes following user feedback can be added.

@rodw-au
Copy link
Copy Markdown
Contributor Author

rodw-au commented May 13, 2026

That should go into tests/motion/heading, that is.
Thanks, the subfolders are a great idea. I tried to get it all in one folder but didn't know enough!
Sometimes, One of the great things about being an Aussie is people like you work our night shift!

You were correct about the divergence. It happened in the first batch of commits and it must have finally bitten. Now fixed. I noticed you corrected the tolerance. But I think its now looser on an inch machine thjan a metric machine. Not sure how to fix that. Can you pass a paramter to the ui file? I guess it won't really matter becasue if its off it will be a G20/G21 issue and it will be far more than that!

@rodw-au
Copy link
Copy Markdown
Contributor Author

rodw-au commented May 13, 2026

You have in the test g-code:

G64 P0.1 Q0.1 	; Tolerance 0.1mm
G21             	; Set units to millimeters
...

Should these two be reversed? First set the machine into metric and then set the tolerance to 0.1mm?

I noticed you had fixed that.

Comment thread src/emc/motion/control.c Outdated
Comment thread src/emc/rs274ngc/interp_write.cc Outdated
Comment thread src/emc/motion/command.c
@rodw-au
Copy link
Copy Markdown
Contributor Author

rodw-au commented May 13, 2026

Oops Fixed command.c. Was looking in the wrong file (control.c) and found some redundant code anyway
Will put formatting in a seperate commit

Comment thread src/emc/motion/state_tag.h
@rodw-au rodw-au requested a review from BsAtHome May 13, 2026 23:14
Comment thread src/emc/motion/control.c Outdated
Comment thread src/emc/motion/control.c Outdated
Comment thread src/emc/motion/control.c Outdated
Comment thread src/emc/rs274ngc/interp_convert.cc
Comment thread tests/motion/heading/heading-test.ngc Outdated
Comment thread src/emc/motion/control.c Outdated
Comment thread src/emc/motion/control.c Outdated
Comment thread src/emc/motion/control.c Outdated
Comment thread src/emc/motion/control.c Outdated
Comment thread src/emc/motion/control.c Outdated
@rodw-au
Copy link
Copy Markdown
Contributor Author

rodw-au commented May 14, 2026

Finally! All cleaned up. Sorry about the stream of commits.
There is now only 2 deletions. One by Luca dealing with Active-tags and the orther was me tidying up a comment in state-tag.h

I'm very relieved our revised gcode passes all tests
Runtest: 281 tests run, 281 successful, 0 failed + 0 expected, 4 skipped, 0 shmem errors

Thanks for all your help and suggestions. It will be great to see this committed now. Some users are keen for it as it was a forum post that spurred me on to get this done. I had an attempt about 6 years ago and gave up but it was good to start afresh with this commit as things had changed and I had done even more silly things than I did in this time!

@BsAtHome
Copy link
Copy Markdown
Contributor

Looks fine to me ;-)

@BsAtHome
Copy link
Copy Markdown
Contributor

@andypugh you need to squash the commits.
There are many individual commits in Rod's tree and many are not relevant to the actual change, but cosmetics. Now, I don't want to cause yet another delay, so squashing this while merging should solve it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants